The use of the Internet as a vehicle for communicating information and exchanging value electronically has resulted in the need for ensuring that such transactions take place in a secure manner. Not only is it imperative that the communication itself be secure, but just as important is the need to ensure that information stored at a data center in a database be secured from tampering. For example, postage metering systems are now available whereby postage value in the form of an indicium can be obtained over the Internet. User accounts that are debited to pay for the downloaded postage are maintained in relational databases at a secure data center and are therefore secure from outsiders. However, there still exists the possibility that someone from within the data center could attempt to alter the postage account database records.
In relational databases, data is stored as a database record. To protect the record, the confidential portion of a database record is encrypted, the record is digitally signed, and the signature is attached to the record. When it is required that information in a particular database record be changed, the manipulation of the database record is only performed in a cryptographic device(s) which holds cryptographic keys for encryption and which digitally signs the manipulated database record. Database records in a relational database may, without adequate precautions being taken, be subject to “replay attacks” wherein an old but legitimate record is used to replace a newly updated record. Without a replay protection mechanism, a cryptographic device cannot detect such an attack.
United States Patent Application Publication U.S. 2002/0161742 (the “'742 application”), owned by the assignee of the present invention, the disclosure of which is incorporated herein by reference, describes systems and methods that provide for the secure management of database records and that protect against replay attacks by detecting such replay attacks as they occur. FIG. 1 shows a data center 1 including a customer database server 3 and a cryptographic device 5 according to one embodiment described in the '742 application. Customer database server 3 includes associated memory in which individual customer records 6 are stored. Each customer record 6 includes a customer identification 7, data 9, a freshness counter 11, and a digital signature 13. Digital signature 13 is created by cryptographic device 5 as discussed in more detail below.
Cryptographic device 5 is used to manipulate data 9 of customer records 6 upon the receipt of an authenticated command. Cryptographic device 5 includes a processor 15 for manipulating data 9 as well as for creating digital signature 13 using stored algorithms and keys 17. Cryptographic device 5 may also encrypt data 9 for additional record security purposes. Cryptographic device 5 also includes non-volatile memory (NVM) 18 in which freshness counters 21 are stored. Each freshness counter 21 corresponds on a one to one basis with one of freshness counters 11 in customer records 6. Each freshness counter 11 and 21 is updated each time the associated individual customer record 6 is manipulated by cryptographic device 5. The freshness counters 11 and 21 used in one embodiment are simply incremental counters that go up by one for each record transaction performed by cryptographic device 5 (freshness counters 11 and 21 are initialized at some default value such as zero). However, the freshness counters 11 and 21 may be any other data that is unique to the individual transaction such as a randomly generated number or a time stamp.
When a customer record 6 has to be updated (because a transaction has occurred relative to that customer record 6), the customer record 6 is sent to and received by cryptographic device 5. Cryptographic device 5 checks the authenticity of the digital signature 13, and decrypts the contents of customer record 6 if encrypted. If the authentication of digital signature 13 (and any required decryption) is successful, then cryptographic device 5 compares freshness counter 11 obtained from customer record 6 against the corresponding freshness counter 21. If freshness counters 11 and 21 match, cryptographic device 5 updates the individual customer record 6 as requested and increments each of freshness counters 11 and 21. The updated customer record 6 is then signed by cryptographic device 5 and the updated customer record 6 with the new digital signature 13 appended thereto is stored at customer database server 3 as an updated customer record 6.
The above procedure solves the replay problem discussed above, because if an old customer record 6 is sent to cryptographic device 5 instead of a current updated customer record 6, the old customer record's digital signature 13 will be authenticated by the cryptographic device 5 but the freshness counter 21 and corresponding freshness counter 11 obtained from the old customer record 6 will not match, thereby providing evidence of a replay attack and allowing appropriate action to be taken by the proper authorities.
While the embodiment shown in FIG. 1 is effective and simple, its usefulness is limited by the size of non-volatile memory 18 of cryptographic device 5. As an example, suppose that one freshness counter 21 is 4 bytes long (the counter value ranges from 0 to 4294967295). To support a million records, the size of non-volatile memory 18 should be as large as 4 mega bytes, which exceeds the capacity of commercially available cryptographic devices. Additionally, for security purposes, freshness counter 21 should not overflow. If it reaches the maximum value, further transactions on such a record must be prohibited.
FIG. 2 shows another embodiment described in the '742 application which overcomes the limitation in the available size of the NVM in cryptographic devices. Data center 23 includes a database server 25 which has stored in associated memory individual customer records 6 as well as a freshness record database 27. Each column 29 (referred to as a freshness record 29) of the freshness record database 27 includes 200 individual freshness counters 11 and an associated total freshness counter 31 that represents the sum of all of the freshness counters 11 of the particular freshness record 29. Data center 23 also includes cryptographic device 35 having non-volatile memory 33. Non-volatile memory 33 stores total freshness counters 37 which correspond to and match total freshness counters 31 that are stored in freshness record database 27. Each freshness record 29 is digitally signed by cryptographic device 35 as discussed further below. The size of total freshness counters 31 and 37 of FIG. 2 should be much larger (preferably 200 times larger) than that of freshness counters 11. However, the size requirement of non-volatile memory 33 of cryptographic device 35 is effectively reduced to 200 times smaller than the non-volatile memory size requirement of the memory 18 of cryptographic device 5 of FIG. 1 since a counter for each customer record 6 is no longer stored in non-volatile memory 33 of cryptographic device 35.
In the FIG. 2 embodiment, the freshness of a customer record 6 is verified as follows. First, the customer database record 6 and the associated freshness record 29 from freshness record database 27 (e.g., customer record 6 for ID 1 and the freshness record 29 corresponding to ID 1) are provided to cryptographic device 35. Cryptographic device 35 then checks the digital signature of both the customer record 6 and the freshness record 29 to verify that they are authentic. Next, cryptographic device 35 compares the value in the total freshness counter 31 extracted from the freshness record 29 with the corresponding value in the total freshness counter 37 of its own non-volatile memory 33. If the values match, cryptographic device 35 extracts the freshness counter 11 from the freshness record 29 and compares the extracted freshness counter 11 against the freshness counter 11 of the customer database record 6. If they match, the freshness of the customer record 6 is verified.
Once the above verification has occurred, cryptographic device 35 performs the requested transaction and manipulates data 9 in the customer record 6 to reflect the transaction (for example, if data 9 represents postage meter accounts, the accounting records would be updated to reflect a transaction where postage was dispensed). Once the transaction is completed, cryptographic device 35 updates freshness counter 11 in the customer record 6, freshness counter 11 and total freshness counter 31 in corresponding freshness record 29, and the corresponding total freshness counter 37 in non-volatile memory 33. Cryptographic device 35 also appends a new cryptographic signature 13 to the customer record 6, cryptographically signs the freshness record 29, and sends the updated customer record 6 and freshness record 29 back to database server 25 for storage.
While the FIG. 2 embodiment uses only a single cryptographic device 35, large-scale systems may require the use of many cryptographic devices in order to support the ability to determine the freshness of a large number of customer records 6. FIG. 4 shows another embodiment described in the '742 application which includes a secure transaction system 41, which uses a plurality of cryptographic servers 36, 38, 40 (and associated cryptographic devices 42, 43, 44, 45, 46, and 47), database server 25, multiple transaction servers 49, and customer database 51 including all customer records 6 and freshness records 29. An example of a cryptographic device would be the cryptographic device from IBM model number 4758.
Transaction servers 49 execute a transaction request from a customer. The transaction servers 49 also serve as a communication relay from one cryptographic device to another cryptographic device. For each even numbered cryptographic device (42, 44, 46) there is a corresponding odd numbered cryptographic device (43, 45, 47). Each of the corresponding odd and even cryptographic devices hold an identical set of total freshness counters 37 for redundancy purposes. The arrangement of the cryptographic devices to their corresponding cryptographic server is such that even if one cryptographic server is out of service, the transaction system 41 still functions. In the embodiment shown in FIG. 4, there is no single point of failure because: (1) there are multiple transaction servers 49, (2) a pair of cryptographic devices share identical total freshness counters 37, and (3) each of the cryptographic devices of a pair of corresponding cryptographic devices is housed in a different cryptographic server. Each of the cryptographic devices 42, 43, 44, 45, 46, and 47 has at least the same functionality as cryptographic device 35 shown in FIG. 2.
The processing of a transaction by secure transaction system 41 makes use of the multi-threading capability of the cryptographic devices, i.e. the capability to process a transaction as well as to verify the freshness of the customer record 6. Thus, in the embodiment shown in FIG. 4, transaction servers 49 can request that a transaction occur at any one of the cryptographic devices 42, 43, 44, 45, 46, 47.
FIG. 3 shows the record structure for a customer record 6 as well as for freshness records 29 that are stored in customer database 51 of FIG. 4 in order to permit the operation of system 41. Each customer record 6 has all the data required to locate the individual freshness counters 11 in the corresponding freshness record 29, i.e., the cryptographic device ID 53, the freshness record ID 55, and the offset 57 of the freshness record 29. Freshness record 29 consists of the cryptographic device ID 53, the freshness record ID 55, individual freshness counters 11, and the total freshness counter 31. In system 41, a particular cryptographic device holds the total freshness counters 37 for a predefined set of customer records 6. Customer records 6 in customer database 51 are used to perform transactions. Examples of such transactions are those that are conducted in an Internet postage system. The postal funds in a customer record 6 can be deducted when the proof of postage is delivered to a customer. Performance of the accounting transaction on the data 9 of the customer record 6 can be executed in any one of the cryptographic devices shown in FIG. 4, while the verification of the freshness of the customer record 6 can be delegated to a different one of the cryptographic devices in the network of cryptographic devices shown in FIG. 4 that has the corresponding total freshness counter 37 stored therein. Further, an individual cryptographic device also may fail. Accordingly, for reliability and backup, total freshness counters 37 are stored on two different cryptographic devices.
The operation of system 41 is as follows. First, a transaction server 49 receives a customer record 6 from the customer record database 51 via the database server 25, and sends it to any available cryptographic device (42, 43, 44, 45, 46, 47), referred to as the chosen cryptographic device. The chosen cryptographic device then verifies the digital signature 13 of the customer record 6, and extracts the cryptographic ID 53, freshness record ID 55, freshness counter 11 and offset 57 therefrom. The chosen cryptographic device then issues a request (which includes the extracted data) to verify the freshness of the customer record 6 to the transaction server 49. The transaction server 49 gets the freshness record 29 identified in the customer record 6 by the freshness record ID 55 from database server 25. Both the freshness record 29 and the request from the chosen cryptographic device are sent by the transaction server 49 to the cryptographic device identified by the cryptographic ID 53 as well as the matching redundant back-up cryptographic device. Both of the identified matching cryptographic devices independently verify the freshness of the customer record 6 in accordance with the procedure discussed above in connection with FIG. 2. The two matching cryptographic devices (one even, one odd) update the freshness record 29 and the total freshness counter 37 and provide the updated freshness record 29 to the transaction server 49 together with a freshness verification message. If either verification fails, the transaction will not be authorized and system 41 can be alerted to the discrepancy. Assuming a successful verification has occurred, the transaction server 49 delivers the verification message to the chosen cryptographic device. If verification has occurred, the chosen cryptographic device updates the data 9 of the customer record 6 to reflect the performed transaction, updates freshness counter 11 in the customer record 6, attaches a new digital signature 13 and sends the updated customer record 6 to the transaction server 49. The transaction server 49 updates both the customer record 6 and the freshness record 29 in database 51 via database server 25.
While system 41 shown in FIG. 4 has been found to be very effective for determining the freshness of a large number of customer records 6 in a large-scale system, it utilizes multiple redundant cryptographic devices and therefore carries with it the extra expense that is associated therewith. Thus, a system for effectively determining the freshness of a large number of customer records 6 in a large-scale system that reduces the number of cryptographic devices that are utilized while at the same time managing and recovering from device failure would be beneficial.